1. Field of the Invention
The invention is related to mobile communications systems. More specifically, it relates to context transfer for seamless inter-domain handover support in heterogeneous networks.
2. Description of the Related Art
The main property of 4G mobile communication networks is the heterogeneity of radio and network technologies. A 4G network can be regarded as an integrated system composed of various networks that present themselves as one network to the end user, with Internet Protocol (IP) as a common basis. A challenge is to provide seamless mobility in such a heterogeneous environment to support interactive applications such as Voice over Internet Protocol (VoIP) telephony.
An IP-based heterogeneous network architecture is assumed, consisting of several inter-connected networks, which may use different network technologies (e.g. Differentiated Services Quality of Service DiffServ QoS, Integrated Services Quality of Service IntServ QoS etc.), different access network technologies (e.g. wireless local area network WLAN, UMTS radio access network UTRAN, . . . ) and may be under control of different operators. The network has mobility support, i.e. a Mobile Node (MN) can move between those networks without breaking connections on higher layers (e.g. Transmission Control Protocol TCP). This process is called “handover” and can e.g. be provided by Mobile IP on layer 3. However, which mechanism is used for this purpose has no effect on this invention.
A handover process comprises various tasks like authentication and authorization at the new network, relocation of radio link and IP session, establishing QoS states in the network etc. To support seamless handover, the performance of the handover has to be improved, i.e. the handover delay has to be reduced. To this end, context transfer can be applied. “Context transfer” is a term for transferring MN-related context or states (e.g. for QoS, header compression, AAA etc) from one network entity (e.g. Access Router AR) to another, so that the MN does not have to re-establish the states in the new network entity from scratch after the handover.
The “seamoby” working group in the Internet Engineering Task Force (IETF) has developed a layer 3 protocol called Context Transfer Protocol (CTP) to enable authorized context transfer between ARs in IP networks (J. Loughney, M. Nakhjiri, C. Perkins, R. Koodli, “Context Transfer Protocol”, IETF Internet Draft draft-ietf-seamoby-ctp-11.txt, August 2004). It supports proactive or predictive context transfer, i.e. transferring the context from the current AR to the next AR before the handover is performed, as well as reactive context transfer, i.e. transferring the context from the previous AR to the current AR after the handover took place. The context transfer can be triggered by the mobile node, the previous AR or the next AR, respectively. CTP defines various messages: Context Transfer Request (CT-Req), Context Transfer Data (CTD), Context Transfer Data Reply (CTDR), Context Transfer Activate Request (CTAR), Context Transfer Activate Acknowledge (CTAA), and Context Transfer Cancel (CTC). These messages are exchanged between mobile node, previous AR and next AR. CTP assumes that MN and AR1 share a key for authorization purposes.
FIG. 1 shows the signalling flow for a proactive context transfer with CTP. AR1 102 and AR2 103 belong to different networks 104 and 105. After determining the IP address of AR2 103 (also called target or next AR/nAR) in S106, e.g. with support of the CARD protocol (see below), the MN 101 sends a CTAR message to AR1 102 (also called source or previous AR/pAR) in S107 which contains the IP address of AR2, the IP address of the MN, a sequence number (SN) to match acknowledgements to requests, an authorization token and the types of context to be transferred. The authorization token is calculated by MN using a hash function and a key that is shared with AR1. AR1 verifies the token and, if successful, transfers the context data in S108 together with the shared key to AR2 using the CTD message. AR2 can acknowledge the receipt with a CTDR message in S109. After the handover, the MN sends a CTAR message to AR2 in S110, which then again verifies the authorization token and installs the context in case of successful verification. Note that the message contains the IP address of pAR and the MN at the time it was attached to the pAR. Finally, AR2 can inform MN in S111 about the status of the context transfer by sending a CTAA message.
FIG. 2 shows the signalling flow in ease of a reactive context transfer. The procedure is similar, but in this case MN/UE 101 first sends a CTAR message to AR2 103 in S201. Thereafter AR2 requests the context from AR1 in S202 using a CTR message. In S203 AR2 receives context data and shared key from AR1 102. Again, AR2 can send a CTAA message to MN/UE 101 in S204 and acknowledge the receipt with a CTDR message sent to AR1 in S205.
CTP is designed for AR-to-AR context transfer only. Heterogeneous networks or other source/target entities are not considered. In case of an inter-domain handover, additional problems arise that are not addressed by CTP as, e.g., different representation of context in source and target network, the need for potentially many inter-domain security associations (SAs) in order to secure the context transfer path or the automatic establishment of those SAs. Consequently a method is needed for context transfer in heterogeneous networks.
The seamoby working group developed another protocol, the Candidate Access Router Discovery (CARD) protocol (M. Liebsch, A. Singh, H. Chaskar, D. Funato, E. Shim, “Candidate Access Router Discovery”, IETF Internet Draft draft-ietf-seamoby-card-protocol-08.txt, September 2004). CARD has mainly two tasks:                Determining the layer 3 identifiers (IP addresses) of the CARs given that the mobile node has obtained layer 2 addresses of the corresponding candidate access points, e.g. by receiving beacons from them; and        Discovering the capabilities of those CARs to assist the mobile node in determining the target AR.        
The protocol can be used to support the determination of the target AR for a predictive context transfer using CTP. The layer 3 identifiers of neighbouring ARs can be determined from the layer 2 identifiers discovered by the mobile node from received beacons using a centralized or a distributed approach. With the centralized approach, a CARD server performs reverse address resolution from layer 2 identifiers. With the distributed approach, information received from mobile nodes during handovers is used to establish a distributed address resolution cache. After the current AR discovered the layer 3 identifier of CARs, it can request information about related capabilities from them and give this information to the MN.
IEEE 802.11f (“Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation”, IEEE Computer Society, IEEE Std 802.11F-2003, July 2003) defines a layer 2 context transfer scheme (mainly for security-related context) to decrease the layer 2 handover delay when reauthenticating and reassociating with a new access point. Therefore, the old and the new access point (AP) exchange IAPP-MOVE or IAPP-CACHE packets for a reactive or proactive context transfer, respectively. In case of a proactive context transfer, APs construct and maintain so-called neighbour graphs based on information received in reassociation-request or IAPP-MOVE.request frames. Neighbour graphs are used to determine candidate APs for the context transfer.
802.11 is designed for AP-to-AP context transfer only. Heterogeneous networks or other source/target entities are not considered. Consequently there is a need for a method for context transfer in heterogeneous networks.
The overall goal of performing context transfer is to reduce the handover delay to support seamless mobility. Thus, the context transfer should be as fast as possible. To achieve this goal, the context transfer should be done in a proactive manner if possible and the context transfer path should be as short as possible. Reactive context transfer should be supported as well in case a handover cannot be predicted early enough. To provide protection against malicious nodes, the transfer must also be secure (per-packet authentication, integrity protection and confidentiality), which requires IPsec security associations (SA) between the source and target entities of the context transfer. An SA usually involves authentication and encryption in the information transfer. All those features are provided by CTP for intra-domain handovers.
However, in case of inter-domain handovers in a heterogeneous environment such as a 4G network, additional requirements must be considered: multiple source/target entities of different kind may be involved, e.g. AAA servers and ARs. Furthermore, source and target network may use different radio and network technologies, e.g., DiffServ and IntServ Qos technology, which may require additional means such as translation of context to a representation which the target network understands. Finally, managing inter-domain SA causes effort, such as key exchange and distribution or may even require manual intervention. Thus, the number of inter-domain SAs should be minimized. Furthermore, previous approaches utilizing management nodes for context transfer do not always use the best path for context transfer, which leads to sub-optimal performance.
WO03052962 describes a system for storing inactive context in a central database (one per administrative domain) and active context in a local context directory located in ARs. A protocol for transferring context between ARs is presented as well. A so-called memory transfer agent is used to transfer only active feature context, i.e. context of active or “in progress”-microflows, from one AR to another. This document supports only a proactive context transfer scheme. The central entity comprises a Main Contact Database (MCD), a Memory Gateway External (MGE) as an interface to other domains and a Memory Gateway local (MGL) as interface to the local ARs. The AR contains a Local Context Directory (LCD), which maintains a list of active contexts of all mobile nodes associated with that AR, a Memory Tranfer Agent (MTA), which is responsible for transferring context between LCDs of different ARs, and a Context Transfer Agent (CTA), which establishes contact to a target AR. When a new microflow becomes active, context is transferred from the MCD via the MGL to the LCD of the current AR. The context transfer is triggered by the mobile node, which sends an ICMP message to the current AR. This message contains a list of target ARs and their preference level. Subsequently, the current AR requests a transfer of the active contexts of this mobile node to the target AR. The target AR may also request additional context from the MCD. In case a handover between different administrative domains is triggered, the context transfer between ARs takes place as usual, but additionally inactive context is transferred between the MCDs of both domains.
WO03052962 like CTP only supports AR-to-AR context transfer, but additionally stores inactive context in a main database. It shifts complexity from the ARs to policy servers in the network, e.g. to perform candidate access router discovery. The context transfer path in case of an inter-domain transfer is always AR1.fwdarw.PS1.fwdarw.AR2.fwdarw.PS2. Thus, each policy server needs (inter-domain) SAs to all edge ARs of adjacent networks, which may lead to scalability problems. Furthermore, a difference of context representation in source and target network leads to incomplete context transfers since no context translation is supported.
In WO03091900, another system is described for proactive transfer of application specific (as opposed to network specific) context between ARs of different administrative domains and access networks. The application specific context is created by the mobile node beforehand. The new AR evaluates the application context and, if necessary, discovers network entities in its domain that support the desired application. For example, the mobile node receives a video stream over a WLAN access network. Before it hands off to a cellular network, it constructs application-specific context containing information about the video stream (bit rate, format etc.) and sends it to the current AR. The AR transfers the context to the next AR of the cellular network, which can then discover and set up a ping-pong tunnel to a proxy server, transcoding the video stream to a lower bit-rate stream.
WO03091900 handles registering and transfer of application-specific functional requirements, e.g. to provide application proxies at the new point of attachment.
In WO02092314, a system is presented that deals with discovering appropriate candidate ARs. It includes a method for detecting, based on the application specific context on the mobile node, a first set of capabilities of a network node that facilitates maintaining an IP session, and a method for querying from a potential next network node capability information and determining if this node is able to fulfil the requirements. The query can be done by the mobile node or the current AR.
WO02092314 focuses on corresponding candidate access router discovery mechanisms and does not provide methods for inter-domain context transfer.
The method presented in WO03049377 utilizes the policy server, a central entity per administrative domain. This server is responsible for selecting possible target ARs. In the first step, all ARs report their capabilities to the policy server. When the mobile node receives information about another AR, it sends identity information, e.g. the layer 2 identifier of the access point, to the current AR which forwards it to the policy server of the current domain. In case of an inter-domain handover, the identifier and other information about the mobile node are sent to the policy server of the target domain. This server determines if it can serve the mobile node. If so, it computes a list of candidate ARs based on given full topology information and according to an algorithm that considers the mobile node's capabilities, the traffic load on the ARs and operator defined rules. The context transfer itself can be performed in a proactive or reactive manner. In the reactive case, the mobile node triggers the context transfer by sending a request message to the new AR. The context is then transferred from the previous AR to the corresponding policy server, which may add static context and may collect dynamic context from other network entities, and sends it to the current AR. In the proactive case, the request message is sent to the current AR and the context is transferred from the current AR over the corresponding policy server to the next AR. In both cases, the target AR additionally transfers the context to its policy server, which can then forward the context to other network entities, like security gateways.
In the system described in WO2004070989, a so-called Core State Management Node (CSMN) is located in the core of the network, which stores, manipulates and forwards context to prevent the need for signalling between ARs. The CSMN can be co-located with an AAA server and may store state data itself or the location of the state if located in another network entity. Both, proactive and reactive context transfers are supported. The mobile node triggers the context transfer by sending a message to the current AR which includes identifiers of the mobile node and of the target AR as well as a region ID in case of a handover between regions. In case of a handover within the region of one CSMN, the previous AR transfers the state to the CSMN, which then stores the state. The next AR then retrieves the state from the CSMN. If a handover takes place between two regions, two CSMNs are involved in the context transfer. In the reactive case, the context is transferred from the previous AR to the corresponding CSMN, which stores the context. After receiving a trigger message from the mobile node, which includes an identifier of the previous region, the next AR can request the state from its CSMN after the handover, which retrieves the state from the CSMN of the previous region. In the proactive case, the context is transferred from the current AR to its CSMN, which stores it and forwards it to the target CSMN. After the handover, the target AR can retrieve the context from its CSMN. Message formats of the context transfer protocol are not defined.
In WO2004070989, again, different context representations and source/target entities are not supported. Additionally, the AR in the new network first retrieves the context from the CSMN after the handover, even in case of a proactive context transfer. Moreover, the context is routed over the CSMNs in both cases, inter- and intra-domain handover. Both issues result in additional handover latency. Also, no protocol is defined for performing the context transfer. Protocols currently in discussion in IETF standardization cannot be re-used since they do not support the proposed architecture.
In WO03092315 a system and method is proposed that performs candidate AR discovery in an external server element, e.g. an application server outside the operator's network. This server is provided with information identifying the AR currently serving the mobile node and the ARs which are within reach of the mobile node. The server then determines one or more target ARs. The capability information needed for the selection algorithm can be initially provided by the operator or dynamically obtained from the mobile node or by querying the ARs. For the latter two approaches, appropriate SAs between the application server and all ARs are needed since the server can be located outside the operator's network. The dynamic candidate access discovery works as follows: the mobile node sends the layer 2 and 3 identifiers of the current and previous AR/AP to the application server after the handover. Thus, the server can establish and maintain an L2-L3 address mapping table and knows which ARs/APs are adjacent. When another mobile node receives layer 2 beacons containing the identifier from adjacent access points, it sends this information to the application server, which then can derive the layer 3 identifier of the corresponding ARs from this information using the address mapping table established before. After knowing the layer 3 identifiers of candidate ARs, information about their capabilities can be requested either by the application server or by the mobile node. Finally, the target router selection can be performed either in the mobile node or in the application server. Furthermore, methods are described for registering application specific context of the mobile node at the application server, which can take care of relocating, e.g., a security gateway, a location server or a proxy. In case of an inter-domain handover, the application server in the old domain discovers respective network entities, e.g. a location server, in the new domain.
WO03092315 only deals with candidate access router discovery. It does not provide solutions for the context transfer itself.
None of the proposals utilizes the context transfer protocol that is currently standardized by the IETF and none of them deals with the efficient automatic establishment and cancellation of SAs.
It is an object of the present invention to provide a method and an apparatus for context transfer in heterogeneous networks, which supports context transfer between access networks using different technologies and minimises the number of required inter-domain security associations.